[chore] Automatically split attribute tables based on deprecation status#3016
[chore] Automatically split attribute tables based on deprecation status#3016thompson-tomo wants to merge 4 commits intoopen-telemetry:mainfrom
Conversation
There was a problem hiding this comment.
The previous PR (#2819) was closed - there is no support for this change among approvers and you've got feedback that this is a controversial change.
See #2623 and #2607 (comment) for the feedback points.
Lack of support from approvers along with the feedback usually means that there is no point in reopening the PR without some discussion. I'm going to close it.
|
@lmolkova i had gone and addressed the controversial points which entered around polluting signals pages with deprecated attributes. This pr makes no changes to which attributes are rendered hence I saw that as closed. It also doesn't introduce a new concept. After which I did raise it at a semconv meeting the other week and the feedback I got was to avoid needing to consolidate yaml files which was also implemented. As it stands the changes introduced here are just:
|
|
thanks for the explanation. Not needing to separate deprecated from active will indeed be useful with schema v2 where we won't have groups anymore. Most of jinja work will need to be redone at that time anyway. I don't believe changes in markdown are beneficial though. And I'd postpone jinja work until we have a need (schema v2). |
|
Would it not be beneficial to extend this PR to also flatten the groups now hence simplifying the jinja changes and get users use to no Grouping. That way when switching to v2 the generated markdown would hopefully not need to change. By having the different layout we can reduce the amount of content being produced and we could even remove the example values if desired to further simplify it. |
Changes
This splits the attribute tables based on the deprecation status.
This provides the following benefits:
Out of scope tasks:
Important
Pull requests acceptance are subject to the triage process as described in Issue and PR Triage Management.
PRs that do not follow the guidance above, may be automatically rejected and closed.
Merge requirement checklist
[chore]